<html>
 <head>
  <meta charset="UTF-8">
 </head>
 <body>
  <h1 data-lake-id="Ddex9" id="Ddex9"><span data-lake-id="ue497ac68" id="ue497ac68">典型回答</span></h1>
  <p data-lake-id="u80560f1f" id="u80560f1f"><span data-lake-id="u63fdd55a" id="u63fdd55a">分布式事务的目的是保证分布式系统中的多个参与方的数据能够保证一致性。即所有参与者，在一次写操作过程中要么都成功，要么都失败。</span></p>
  <p data-lake-id="ua85b031b" id="ua85b031b"><span data-lake-id="ub603304a" id="ub603304a">​</span><br></p>
  <p data-lake-id="u88126000" id="u88126000"><span data-lake-id="u754ce643" id="u754ce643">至于这个一致性到底是怎样的一致性，是强一致性、还是最终一致性，不同的分布式事务方案其实达到的效果并不相同。</span></p>
  <p data-lake-id="u753e4f4b" id="u753e4f4b"><span data-lake-id="ud662aacc" id="ud662aacc">​</span><br></p>
  <p data-lake-id="ude2da5de" id="ude2da5de"><span data-lake-id="u9eb8b683" id="u9eb8b683">如果想要实现强一致性，那么就一定要引入一个协调者，通过协调者来协调所有参与者来进行提交或者回滚。所以，这类方案包含基于XA规范的二阶段及三阶段提交、以及支持2阶段提交的第三方框架，如Seata，还有TCC也是一种强一致性的方案。</span></p>
  <p data-lake-id="u7a0c9f36" id="u7a0c9f36"><span data-lake-id="u84570282" id="u84570282">​</span><br></p>
  <p data-lake-id="ue572f024" id="ue572f024"><br></p>
  <p data-lake-id="udcba1a0c" id="udcba1a0c"><br></p>
  <p data-lake-id="u2c401ea9" id="u2c401ea9"><span data-lake-id="ud93f8de0" id="ud93f8de0">如果想要实现最终一致性，那么方案上就比较简单，常见的基于可靠消息的最终一致性（本地消息表、事务消息）、最大努力通知、以及借助Seata等分布式事务框架都能实现。</span></p>
  <p data-lake-id="u6e9a841d" id="u6e9a841d"><span data-lake-id="u55a24178" id="u55a24178">​</span><br></p>
  <p data-lake-id="u1e483b31" id="u1e483b31"><br></p>
  <p data-lake-id="u66876615" id="u66876615"><br></p>
  <p data-lake-id="ub22db2d3" id="ub22db2d3"><span data-lake-id="u8f39bb4b" id="u8f39bb4b">​</span><br></p>
  <p data-lake-id="u11b472f3" id="u11b472f3"><span data-lake-id="ue957d867" id="ue957d867">可靠消息实现最终一致性的方案其实就是借助支持事务消息的中间件，通过发送事务消息的方式来保证最终一致性，过程及原理可以参考：</span></p>
  <p data-lake-id="u167a6706" id="u167a6706"><span data-lake-id="u3deb07c4" id="u3deb07c4">​</span><br></p>
  <p data-lake-id="u06eecfe7" id="u06eecfe7"><span data-lake-id="u40d0c548" id="u40d0c548">​</span><br></p>
  <p data-lake-id="ue8a0e405" id="ue8a0e405"><span data-lake-id="ue9df32eb" id="ue9df32eb">​</span><br></p>
  <h1 data-lake-id="QnpXo" id="QnpXo"><span data-lake-id="u5726d43e" id="u5726d43e">扩展知识</span></h1>
  <p data-lake-id="u6cdde19d" id="u6cdde19d"><br></p>
  <h2 data-lake-id="xh3rw" id="xh3rw"><span data-lake-id="u63afe8ab" id="u63afe8ab">如何选择</span></h2>
  <p data-lake-id="uc10581e0" id="uc10581e0"><br></p>
  <p data-lake-id="u02c1be19" id="u02c1be19"><span data-lake-id="u1e223e63" id="u1e223e63">在选择一个分布式事务方案的时候，需要考虑很多因素，结合自己的业务来做考量选择。一般来说可以有以下几种选择方式：</span></p>
  <p data-lake-id="u299e0ee9" id="u299e0ee9"><span data-lake-id="u133c2c79" id="u133c2c79">​</span><br></p>
  <p data-lake-id="ue0249718" id="ue0249718"><strong><span data-lake-id="u3e2b8a09" id="u3e2b8a09">1、实现成本</span></strong><span data-lake-id="u73a78a27" id="u73a78a27">：根据项目开发和维护的难度、成本等方面来选择合适的分布式事务方案。这几种方案中，TCC和2PC的实现成本最高，业务侵入性也比较大。</span></p>
  <p data-lake-id="udab48ca4" id="udab48ca4"><span data-lake-id="ufae706a8" id="ufae706a8">​</span><br></p>
  <p data-lake-id="ub22f11e4" id="ub22f11e4"><span data-lake-id="u7875d68f" id="u7875d68f">另外，事务消息、本地消息表和最大努力通知都依赖消息中间件，所以如果已有业务已经接入了消息中间件的话，那么使用成本还算可控，否则就需要考虑消息中间件部署、维护和接入成本。而且同样是消息中间件，也不是所有的都支持事务消息，这个也是需要考量的一个重要因素。</span></p>
  <p data-lake-id="u275e0776" id="u275e0776"><br></p>
  <p data-lake-id="u18cbe449" id="u18cbe449"><strong><span data-lake-id="u2253b825" id="u2253b825">2、一致性要求：</span></strong><span data-lake-id="ue4aeaf9e" id="ue4aeaf9e">在一致性方面，2PC和TCC属于是可以保证强一致性的，而其他的几种方案是最终一致性的方案。</span></p>
  <p data-lake-id="u1918cb79" id="u1918cb79"><br></p>
  <p data-lake-id="u3af37666" id="u3af37666"><span data-lake-id="u3fc94bb1" id="u3fc94bb1">根据业务情况，比如下单环节中，库存扣减和订单创建可以用强一致性来保证。而订单创建和积分扣减就可以用最终一致性即可。而对于一些非核心链路的操作，如核对等，可以用最大努力通知即可。</span></p>
  <p data-lake-id="uecb4d7ea" id="uecb4d7ea"><span data-lake-id="u37d97c89" id="u37d97c89">​</span><br></p>
  <p data-lake-id="u1ad93f9e" id="u1ad93f9e"><strong><span data-lake-id="ub8d18a98" id="ub8d18a98">3、可用性要求：</span></strong><span data-lake-id="ubfbfdb14" id="ubfbfdb14">根据CAP理论，可用性和一致性是没办法同时保证的，所以对于需要保证高可用的业务，建议使用最大努力通知等最终一致性方案；对于可用性要求不高，但是需要保证高一致性的业务，可使用2PC等方案。</span></p>
  <p data-lake-id="ua15ee9b0" id="ua15ee9b0"><span data-lake-id="ud86d0545" id="ud86d0545">​</span><br></p>
  <p data-lake-id="u63fffec7" id="u63fffec7"><strong><span data-lake-id="uee519948" id="uee519948">4、数据规模：</span></strong><span data-lake-id="u8094f1bf" id="u8094f1bf">对于利用消息中间的这种方案，其实不是特别适合业务量特别大的场景，有可能出现消息堆积导致一致性保障不及时。对于数据量大的场景，可以考虑Seata方案。</span></p>
 </body>
</html>